Event Bus Pattern 이란?
특정 이벤트가 발생하였을 때 이벤트가 발생했다는 사실을 외부 클래스에게 알려주는 방법에는 어떤 것이 있을까요?
외부 클래스는 해당 이벤트가 발생했다는 것을 알아차리기 위해 항시 대기를 하고 있어야 하는걸까요?
항시 대기라고 한다면 Unity Update()메소드를 이용하여 매 프레임마다
원하는 값을 받아오고 상태가 바뀌었는지 확인하는 방법이 있을 것 같은데요.
좋은 방법이라고 생각이 되지는 않습니다.
이러한 상황에 이벤트 버스 패턴을 활용할 수 있습니다.
이벤트 버스 패턴은 발행/구독 패턴의 형식을 띄는 패턴입니다.
Event Bus Pattern의 구성
Publisher : 이벤트 게시자
Subscriber : 이벤트 구독자로, 이벤트가 발생하면 Bus를 통해 알림을 받습니다.
Bus : 구독자에게 이벤트를 등록해주고, 이벤트가 발생할 경우 Publisher에게서 신호를 받아 Subscriber에게 알려주는 역할을 합니다.
Event Bus Pattern의 구현
[EventType]
1 | public enum EventType{ |
[EventBus]
1 | public class EventBus{ |
[StartCount] : 구독자이자 발행자 역할을 하는 클래스
1 | public class StartCount : MonoBehaviour |
오브젝트가 활성화 되었을 경우 event 구독을 시작하고 비활성화되었을 경우 더이상 이벤트 알림을 받을 필요가 없으므로 구독 취소를 해줍니다.
위의 클래스는 활성화되었을 경우 COUTNDOWN 이벤트를 구독하고
Countdown이 실행완료되면 START 이벤트를 발행합니다.
게임시작 버튼을 눌러 COUNTDOWN이벤트가 발행된다면 위의 작업이 실행됩니다.
Event Bus Pattern의 장단점
장점
이벤트 버스는 게시자와 구독자 간 느슨한 결합을 유지시켜줍니다.
오브젝트들이 서로 직접 참조하지 않고 이벤트를 통신할 수 있습니다.
이는 굳이 게시자와 구독자가 누구인지 알아둘 필요가 없다는 것을 뜻하기도 합니다.
단점
전역적으로 접근하기 때문에 디버깅과 유닛 테스트를 어렵게 함으로 프로젝트 관리 또한 어렵게 만든다.
Event Bus 사용 시기
빠른 프로토타이핑 : 분리 상태를 유지하면서 이벤트로 각자 다른 동작을 하는 컴포넌트를 쉽게 생성할 수 있었습니다. 빠르고 쉽게 프로토타이핑하고 싶을 때 사용하기 좋습니다.
프로덕션 코드 : 게임 이벤트를 더 정교하게 관리하지 않아도 되는 프로덕션 코드에서 사용할 수 있습니다.
복잡한 이벤트 타입이나 구조체를 다루지 않아도 될 경우 이벤트 버스 패턴의 이점이 보입니다.
Event Bus 패턴과 Observer 패턴
이벤트 버스 패턴과 옵저버 패턴은 비슷한 성향을 지니고 있지만 명백하게 차이점이 있습니다.
이는 Event bus의 여부로 볼 수 있습니다.
옵저버 패턴의 경우 Subject(구독자)가 옵저버를 등록하고 직접 옵저버에 알려주어야 하지만,
이벤트 버스 패턴의 경우 Event Bus에 메시지를 전달하기만 하면 구독자와 게시자의 존재를 파악할 필요가 없다는 점입니다.
Event Bus 패턴의 대안
옵저버 : 서브젝트가 옵저버 목록을 유지 관리하고 내부 상태 변경을 알리는 패턴입니다.
이벤트 큐 : 게시자가 생성한 이벤트를 큐에 저장하고 편한 시간에 구독자에게 전달하는 패턴입니다.
[참조]